Dear all,

as discussed at the last IETF I have reviewed draft-gellens-ecrit-ecall-03.txt.
Here are my comments:

General:
1.      ETSI has finalized the Technical Report on eCall and proposes solutions. Question is if it would be worth to mention onr reference it. The report is under http://webapp.etsi.org/ewp/copy_file.asp?wki_id=39297  downloadable.

2.      I will point in some parts of the detailed review to backwards compatibility issues. So we have now implemented a eCall solution for our GSM. So this is an invest done. And PSAP invests are seen as a long term invest. These will be used for a long time so a SIP/IMS/NGN solution is needed where we can built new PSAP understanding the NG-eCall but also have the possibility to route the call towards the "old" PSAP getting the inband information type eCall. But also the case will appear where we have still the old style end device which have to be interworked towards the new PSAP style. Question is how this will be done? My opinion is that each PSAP has to understand the in-band information.


Detailed comments & questions:
1.      Section 3 last paragraph:
...
An eCall
   flag in the call setup marks the call as an eCall, and further
   indicates if the call was automatically or manually triggered.
...
3GPP has more flags that only automatic and manual. (we have discussed this in Berlin)

the proposal is to add an sentence like:
"Note that 3GPP TS22.101 allows to combine the automatic and manual triggered ecall with the type of emergency guard like police or fire force. This is also uses in some countries."
3GPP describes the requirements in TS 22.101 as follows

Possible values in signalling:

   o Police

   o Ambulance

   o Fire Brigade

   o Marine Guard

   o Mountain Rescue

   o Manually Initiated eCall

   o Automatically Initiated eCall

   And the bind requirement:

   It shall be possible to tie any emergency call number to any single
   emergency call type or to any combination of emergency call types.


2. Section 3.
Also it would be worth to mention that backward compatibility is an requirement since we have already millions of cars with GSM Chips which will be in future interworked with SIP/IMS networks.

3.Section 4.
one requirement is the backwards compatibility. Since mobile networks will not have LTE coverage  all over and "old" ecall solutions will be interwokked to IMS there is the need when to have a backwards compatible solution. (i.e. Inband communication must be traversed to PSAP understanding in band and/or the PSAP is able to understand in- and out-band information.

4.      Section 6. 1st Paragraph :
      "In circuit-switched eCall, the IVS places a special form of a 112
   emergency call which carries the eCall flag (indicating that the call
   is an eCall and also if the call was manually or automatically
   triggered)... "
As mentioned above there are more possible indications within the "eCall Flag"
5. Section 6 2nd Paragraph: Perhaps mention a option to identify also inband information when available. Or note that inband information then should be routed towards an backwards compatible PSAP.

6. Section 6. last Paragraph: "...urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual" From the discussion we had in the past (i.e http://tools.ietf.org/html/draft-jesske-ecrit-ecall-urn-extension-01 in Berlin) I had the understanding that also the extension of the  urn:service:sos.ecall.automatic is still to long. So that only  urn:service:sos.ecall would be more ort less acaptable. And we need an further extension to identity the additional information for routing.

7. Section 7.  "...   The routing rules for eCalls are likely to differ from those of other
   emergency calls because eCalls are special types of emergency calls
   (with implications for the types of response required) and need to be
   handled by specially designated PSAPs.
 What is meant by "with implications for the types of response required" I do have slide problems to understand. Is this the fact that there could be diffrent responses like a call back or SMS back?


8.       Section 7.1 mentions a interworking new to old. Is there also the possibility to interwork old to new? Would there be also an Section 7.2, 7.3 for other networks which are not EENA based?

9.      Section 9. Will the same mechanism used or is this one out of a several possibilities? Is this mechanism such as open that each PSAP-operator can define it's own set? Or is it more seen as set to be aligned within RFC's?

10.     Section 10. It would be worth if preconditions and the reliability of provisional responses will have a effect of the solution or if they are needed? This question reflects the issue that in many mobile IMS networks such mechanisms will be used.
11.     A IVS provided location could be also manipulated. Independent on the trustworthiness. I think this should be mentioned explicitly. Question is what can provide security on such location. Perhaps a hint would we nice to be mentioned or to mandate the draft trustwothy-location more as an requirement.

12.     Section 12. As commented above I would propose an additional URN parameter or an other SIP extension to point to the possible indications appearing within a eCall. Such a indication needs to be considered when routing towards the PSAP.


13.     Within 3GPP we have the additional indications as mentioned above


>From my (operators) point of view the most important points needed to be discussed are backwards compatible solution and the format of the URN and additional indication for PSAP routeing purposes.

My recommendation is also that we can start the work and push it towards work item within ecrit.

Thank you and Best Regards

Roland

Mit freundlichen Grüßen; With Best Regards
Roland Jesske

Deutsche Telekom Technik GmbH
Fixed Mobile Engineering Deutschland
Roland Jesske
Heinrich-Hertz-Straße 3-7, 64295 Darmstadt
+49 6151 58-12766 (Tel.)
+49 6151 58-13395 (Fax)
+49 171 8618-445 (Mobil)
http://www.telekom.com

Erleben, was verbindet.

Deutsche Telekom Technik GmbH
Aufsichtsrat: Dr. Thomas Knoll (Vorsitzender)
Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Carsten Müller
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr.: DE 814645262
Große Veränderungen fangen klein an - Ressourcen schonen und nicht jede E-Mail drucken.